本文是「測試之外的那一半：一個 QA 回頭帶當年的自己」系列第 19 篇。
我開發了一套 Android App 的自動化測試。每天要跑。
跑之前有一個前提：機器上必須有這一版的 APK。不是上週那版，是今天要驗的那版。
而那個 APK 怎麼來的？
有人打開發布後台，找到今天的建置，點下載，再把檔案傳到測試機上。
那個人常常是我。
這件事放著不管也能跑。每天花五分鐘，不算什麼。
但它有兩個真實的代價。
測試沒辦法排程。 我不能設定成半夜自己跑，因為半夜沒有人會去點那個下載。
我常常測到錯的版本。 下載、傳檔、確認版號，每一步都可能手滑。而測錯版本最討厭的地方是，你要到結果很奇怪的時候才會發現。
所以我想把這一段接起來。
這件事卡在兩個團隊中間。
建置那一邊的職責是「把 APK 產出來，放到發布後台」。做完了，他們的部分就結束了。
測試這一邊的職責是「拿到 APK 之後驗它」。從拿到開始算。
中間那一段——怎麼從後台把檔案送到測試機——不在任何一邊的描述裡。
所以它被一個人每天花五分鐘手動補起來，補了很久，而且沒有人覺得這是個問題。因為從外面看，測試每天都有跑。
這就是這一週講的東西又一次出現。只是這次掉在縫隙裡的不是一份文件、不是一張 bug 單，是一個下載動作。
第一條：打發布平台的官方 API。 幾個 HTTP 呼叫，拿到檔案。有文件、有版本保證、介面要改會先公告。
第二條：寫爬蟲，模擬人去後台把檔案抓下來。 依賴頁面結構，人家改版就會壞，而且壞的時候不會有人通知你。
任何工程師看這兩條都會選第一條。我也選了第一條。
然後我拿到 403。
那個 API 在這個專案沒有被啟用。要啟用，得有人去平台後台開。
而且不只開一次。服務帳號要在每一個子專案被逐一授權，而那些子專案分屬不同團隊。
所以第一條路的真實成本不是「幾個 HTTP 呼叫」。是：找出每個子專案的負責人、說明我要做什麼、請他們幫我加權限，然後每次新增子專案的時候重來一遍。
那是跨部門的權限治理問題。寫程式解不了它。
我最後選了爬蟲。它醜、它脆、它會在別人改版的時候壞掉。
但它有一個決定性的優點：它用的是我的帳號。
我本來就看得到那些專案。零設定、零申請、零跨部門協調。
爬蟲贏不是因為技術上比較好。它贏是因為它繞過了一個我搬不動的關卡。
選路線之前先問一句：這條路的瓶頸在技術，還是在組織？
技術瓶頸你可以自己解。多花兩天讀文件、多寫兩百行、多跑幾次實驗，它會被解掉。
組織瓶頸不會。它需要一個有權限的人做決定，而那個人多半不是你，他的優先順序表上可能根本沒有這一條。
兩種瓶頸長得很像，因為它們都表現成「這個方案現在跑不起來」。
分辨的方法是問：如果我今天完全不睡覺地做，明天有沒有可能解掉？
技術瓶頸的答案是有機會。組織瓶頸的答案是沒有，因為那不是我的鍵盤打得出來的東西。
Day 5 我講過自己怎麼把一件事拖了兩個月。那時候卡住我的，是我拿一個需要跨部門對齊的方案，去解一個當下只需要先動起來的問題。
這次是同一個岔路口，但我做了不一樣的選擇。
我沒有去推那個 API。不是因為 API 不好，是因為我算出來那條路的成本不在我的能力範圍，而在別人的行事曆上。
而且我把這件事寫進了決策紀錄：我知道爬蟲是技術債。我選它，是因為另一條路的債更貴，只是那筆債記在組織帳上，不記在我的帳上。
寫下來很重要。哪天有人要推那個 API 了，那份紀錄就是他的彈藥——成本在哪一層，已經幫他算好了。
半夜可以自己跑了。我不用再每天點那五分鐘，也不會再測到錯的版本。
那個縫隙還在。沒有人去定義「建置到測試之間這段歸誰」，我只是用一條醜路把它跨過去。
哪天那個後台改版，它就會壞，然後我會再補一次。
但在那之前，它每天幫我省五分鐘，而且省掉了那個會讓我白測一輪的手滑。
寫到這裡我得補一件事，不然這篇會變成在教人怎麼繞路。
爬蟲是替代方案。正解還是把 API 那條路打通：該開的權限開了、該授權的子專案授權了，整條路徑被驗證過是完整、可行、穩定的。
而要走正解，我該做的事其實很清楚：去找主管請他出面，或者直接找 IT、找 MIS，請他們幫忙把跨專案的權限打通。
這就帶到一件我很後來才看懂的事。
測試這份工作，有很大一部分不是你一個人做得完的。
你會卡在權限、卡在環境、卡在某個你根本沒有帳號的系統。這些沒有一個是靠技術能力突破得了的。你只能去問人。
寫腳本可以靠自己，打通一條路不行。
如果你還在學，這段聽起來可能很遠。但你已經在做同一件事了。
你要辦一個活動，得找行政幫你跑流程。你要申請一個計畫，得先拿到教授的許可。那些事情不是你把企劃寫得夠好就會成立的，它們需要別人在他的位置上幫你蓋一個章。
工作之後只是把這個結構放大。差別在於學校裡那些流程多半有明文規定，而公司裡很多事情沒有。
我實習的時候沒有把這兩件事連在一起。我以為學校的行政流程是學校的麻煩，進了公司就會變成「大家都很專業、照著做就好」。
結果是更多的跨部門，只是沒有表格可以填。
但「去問人」說起來比做起來容易。
對 MIS 或 IT 來說，幫我開這個權限是額外的工作。它不在他們的排程上、不會讓他們的數字變好看，而且開權限對他們是有風險的——出事的時候要解釋的人是他們。
所以真正要回答的問題不是「我需要什麼」，是：幫我這個忙，對他有什麼好處？
這個問題不只對 IT 要問。
自動化順利跑起來，對 PM 有什麼好處？對 RD 有什麼好處？如果答案是「測試比較快」，那對他們其實沒有好處，那是我的好處。
要有好處，得講到他們身上：RD 推上去之後更快知道有沒有弄壞東西；PM 不用在上線前一天才聽到壞消息。
這題我到現在也答得不好。
我想得到最好的說法是：這條路打通之後，往後每一個要做同樣事情的人都不用再來煩他們一次。用一次性的設定，換掉之後零星重複的請求。
但這個說法成不成立，取決於「之後會不會真的有人來」。如果只有我一個人要用，那對他們來說就是純粹的額外工作，而我說不出第二個理由。
Day 5 那篇講的大人學處理的正是這件事：做一件事之前，先想清楚牽涉到哪些部門，各自的利益點在哪裡。
Day 5 我講的是這套思考被我用錯了時機，把自己卡死兩個月。這一篇是它的另一面：時機對的時候，它就是唯一的路。
分野在於你手上有沒有「現在就能動」的替代方案。有的話，先動起來，跨部門那一輪留到下次。沒有的話，那就只能去談。
而這整件事有一個前提：你得先踩過那個坑，才知道它有多深。
我是真的去打了那個 API、真的吃到 403、真的翻完權限設定之後，才知道這條路需要的是跨部門協調，不是我再多寫兩百行就能通的。
在那之前我不可能知道。坑沒踩過，你講不出「我卡在哪裡」，而講不出卡在哪裡，就沒有人幫得了你。
但踩完之後就該停。那時候要問的是：
這件事我一個人能做到什麼程度？剩下的該交給誰？
交給主管，如果它需要一個有職權的人出面。交給旁邊的 QA，如果對方剛好碰過同一個系統。交給別的部門，如果鑰匙本來就在他們手上。
Day 13 我講過停損的判準：我這一小時學到的東西，還在增加嗎。
這一篇是它的下半句：停下來之後，要交給誰。
有兩個方案在你面前的時候，除了比技術，多問一句：
這兩條路各自卡在哪一層？如果我今天不睡覺地做，哪一條明天有機會通？
明天有機會通的是技術問題。明天不可能通的是組織問題。
選了繞路的那條，記得把「我為什麼繞路」寫下來。那份紀錄有一天會變成某個人把路修直的理由。
而如果你決定去把路修直，先想好兩句話：
這件事做完，對幫你的那個人有什麼好處？
我一個人能做到哪裡，剩下的該交給誰？
明天聊：那些沒人負責的事，你要靠什麼推動。
iThome鐵人賽
看影片追技術